This application relates in general to computer systems utilizing an emulator, and in specific to mechanism for handling signals during the emulation of system calls.
Software applications utilize the functionality provided by the underlying operating system during execution time. As shown in FIG. 2, the functionality, such as manipulating files, shared memory, and semaphores, is usually provided in libraries 22 along with an application program interface (API) 21. The operating system 24 implements most of this functionality internally by means of a set of system calls 25. The interface between the libraries and the system calls in the operating system is provided by an application binary interface (ABI) 23. Thus, a software application 11 will make system calls 25 to the operating system 24, via the API interface 21 with the libraries 22 and the ABI interface 23 with the operating system.
Most software applications are developed to operate on one particular type of platform, and thus will not directly run on a different type of platform. A variety of mechanisms have been developed to allow software applications to run on different platforms. One particular mechanism is an emulator which emulates the software application on a different platform from that which it was developed to run. For example, FIG. 1 depicts software application xe2x80x98Axe2x80x99 11 which was developed to run on platform xe2x80x981xe2x80x99 12. Application xe2x80x98Axe2x80x99 11 cannot run on a different type of platform, platform xe2x80x982xe2x80x99 13, unless emulator 14 emulates the code of software application 11 for use on platform xe2x80x982xe2x80x99 13. Emulators are also used in testing and prototyping software applications.
Emulators 14 are typically software mechanisms which are resident in the second platforms, i.e. platform xe2x80x982xe2x80x99 13. The emulator exactly reproduces the operating environment expected by the software application. The emulator does this by emulating both the instruction set architecture (ISA) of the platform, which refers to the machine instructions in the software, and the environment, which refers to the system calls, signals, etc. used by the software. Part of the environment emulation involves emulating the signals and the system calls provided by the operating system which ordinarily would be directly visible to the software application.
A problem occurs during the emulation of the system calls, particularly with signals which occur during the emulation. Signals are mechanisms provided by the operating system to notify processes or software applications about events that have occurred. Signals are usually classified into synchronous or asynchronous. Synchronous signals are caused by the execution of the software application, and thus, are delivered immediately, at well defined points in the emulated application program code. Asynchronous signals are caused externally and are not delivered at any precise location, i.e., the delivery location is indeterminate. Thus, asynchronous signals need not necessarily be delivered immediately after they occur. Moreover, an emulator may need to delay delivery of asynchronous signals because the emulated application may not be in a state consistent with the arrival of the signal when the signal arrives. Consequently, asynchronous signals are deferred until the emulated application 11 is in a proper state to receive such a signal.
A system call is a mechanism that transfers control from the software application to a specified functionality of the operating system of the platform. The emulator can emulate most system calls made by the emulated software application by mapping them onto the system calls provided by the operating system of the second platform, i.e. platform xe2x80x982xe2x80x99 13. A system call may be interrupted by an asynchronous signal.
A problem would occur if a signal were deferred during the emulation of a system call. The signal would not be delivered until the emulation of the system call was completed, which is when the emulated application is in a proper state to receive such a signal. In order to emulate the system call, the emulator makes a corresponding system call to the native operating system. The native system call will block whenever the corresponding system call would have blocked on the legacy system. If the emulated application is relying on the fact that a blocked system call will be interrupted by a signal, the application will not function correctly under the emulator, since the deferred signal would no longer be able to interrupt the system call, and the system call will block forever.
FIG. 3 depicts an example of the problem occurring during the emulation of system calls. Software application 11 makes a system call, read( ) 31, with the assumption that a signal, SIG_X 32, will interrupt the system call and thereby cause control to return to the application. As shown in FIG. 3, the signal SIG_X 32 occurs after emulation 33 of the read( ) 31 has commenced and before the system call has been mapped 34 to an equivalent system call in the second platform, platform xe2x80x982xe2x80x99 13. After mapping, control is transferred 36 to the kernel of the operating system 24. If the emulator defers SIG_X for later delivery 35 instead of immediate delivery, then the read( ) system call will block or hang indefinitely because it is waiting for SIG_X to interrupt it, which can no longer interrupt it because it has already been deferred. Thus, the operating system is waiting for the signal 37 before returning to the emulator 38, and completing the system call 39. Note that emulator 14 performs additional steps during emulation of the system call which are depicted by . . . characters in FIG. 3. These steps will vary, depending upon the specific system call being emulated, and thus are not shown here.
Therefore, there is a need in the art for a mechanism which will deliver any asynchronous signals that either arrive or are pending during the emulation of system calls.